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(57) Abstract: The present invention relates to a method and system for scheduling data packets in a base station device of an 
access network. An information indicating a retransmission status of a data packet is provided to the base station device, and a 
scheduling priority is allocated to the data packet based on the retransmission status information. Thereby, retransmission packets 
can be scheduled earlier and round trip times can be reduced, so as to decrease the risk of timeouts and stal lings and to loosen buffer 
requirements. 
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Scheduling Retransmission in Access Networks 

FIELD OF THE INVENTION 

The present invention relates to a method and system for scheduling data packets 
in a base station device of an access network which provides access to a packet 
5 data network. 

BACKGROUND OF THE INVENTION 

Within the International Telecommunications Union (ITU), several different air in- 
terfaces are defined for third generation mobile communication systems, based on 
either Code Division Multiple Access (CDMA) or Time Division Multiple Access 
10 (TDMA) technology. Wideband CDMA (WCDMA) is the main third generation air 
interface and will be deployed in Europe and Asia, including Japan and Korea, in 
the same frequency band, around 2GHz. 

The WCDMA air interface has been defined to provide, in the first phase, data 
rates up to 2 Mbps in the 3GPP (third generation partnership project) Release 99 

15 and Release 4 specifications. In the Release 5 specification, peak data rates up to 
10 Mbps are possible with a High Speed Downlink Packet Access (HSDPA) fea- 
ture to thereby support packet-based multimedia services. In HSDPA, the intelli- 
gence of the base station device or Node-B (which is the third generation equiva- 
lent to the former base station) is increased for handling of retransmissions and 

20 scheduling functions, Thereby, L1 retransmission between the user equipment 
(UE, which is the third generation equivalent to the former mobile station) and 
Node-B are introduced and the round trip delay of these are lower than 'normal' 
RLC retransmission round trip delays. However there will still be (a little fraction of) 
RLC retransmission also for HSDPA.. This makes retransmission combining feasi- 

25 ble in the mobile device due to reduced memory requirements. In general, all 

HSDPA users share the channel in both time and code domains. Adaptive modu- 
lation and coding is used to support multiple rate transmissions for different types 
of multimedia services. 

With HSDPA, the Node-B is responsible for scheduling different users on the High 
30 Speed Downlink Shared Channel (HS-DSCH) and as such, the user data to be 
scheduled must to some extent be buffered in advance in the Node-B. The user 
data is sent from the RNC to the Node-B by means of a mapping operation bet- 
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ween a packet data unit of the Radio Link Control protocol layer, i.e. RLC-PDU, 
and a packet data unit of the Medium Access Control protocol layer, i.e. MAC-d- 
PDU, which is transmitted over the lub or lur interface, i.e. the interfaces between 
the RNC and the Node-B and between different RNCs, respectively. When the 
5 data has been sent to the Node-B, the RNC is unaware of its status until it re- 
ceives a response or acknowledgment. In particular, the sender side polls the re- 
ceiver which on its turn answers with a status report, telling the status of the out- 
standing RLC blocks, after some significant time delay. The RLC layer response 
algorithm can be controlled using the so-called polling bit, but some minimum de- 
1 0 lay is inherent to the network. 

To provide the highest system capacity gain, it is assumed in 3GPP standardiza- 
tion that the so-called proportional fast scheduling strategies will be employed. 
This scheduling method chooses that user for scheduling, which has the best rela- 

15 tive channel quality at a given time, thereby optimizing cell throughput while pro- 
viding the users with approximately the same access probability to the channel. 
The basic concept for this type of scheduling is "multi-user diversity"; e.g. the abil- 
ity to choose the best user from a large set of users. Hence, for this method to 
work optimally, it is important that the scheduler can pick the most optimum user at 

20 any given time instance which means that an excess amount of data, compared to 
what is actually scheduled on the channel, has to reside in the Node-B MAC-hs 
buffer. 

However, the provision of such large buffers leads to the following problems: 

25 

• At some point, RLC PDUs, which are located in the Node-B may be retransmit- 
ted by an RLC retransmission from the RNC. Reason for this is that in the 
status report it is indicated that there are some RLC blocks missing. It should 
be noted that the RNC does not know whether the data is still waiting to be 

30 scheduled in the Node-B, whether it was sent but the UE failed to detect it, or 
whether the uplink response or acknowledgement was lost during transmission 
from the UE. If there are always provided e.g. 3-4 times as much data as the 
average capacity stored in the Node-B in order to facilitate sufficient multi-user 
diversity, quite some data sent over the lub/lur interface has to be retransmit- 

35 ted, which leads to an excessive and highly undesirable load on this link. It is 
however noted that the RLC layer will only retransmit those blocks missing, not 
all blocks. It is thus a selective retransmission algorithm. 
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• Non-real time (NRT) services are often running over services which use the 
Transport Control Protocol (TCP). TCP has its own congestion avoidance algo- 
rithm, including features like fast retransmissions, timeouts, etc. TCP timeouts 
works as follows: Every time a TCP segment is sent, a timer is started. This 
5 timer is compared to the RTO (retransmission timeout), which equals the fil- 
tered estimated TCP RTT (round trip time) plus 4 times the filtered estimated 
variance of the TCP RTT. If the timer is exceeding the RTO value, congestion 
actions are started, as TCP assumes the segment to be lost or delayed due to 
congestion. These congestion actions consist among others of retransmitting 

10 all segments from the segment in question and starting the slow start algo- 
rithm. TCP slow starts are undesirable since they lead to low utilization of the 
transmission medium. From the above it can be understood that sudden very 
large delays for some blocks may lead to TCP timeouts. The delay caused by a 
RLC retransmission is considerable, since the retransmission is put at the back 

15 of the queue in the Node-B. Since RLC retransmissions only happen very sel- 
dom, the RTO algorithm cannot adjust to them. Thus, an RLC retransmission 
creates a sudden delay increase which may be interpreted by TCP as 
congestion, leading to undesirable congestion actions. 

20 • The RLC transmission is based on an RLC window. The working of this can be 
explained with an example, which is shown in Fig. 7. The amount of out- 
standing data can never be more than the size of the window. As soon as the 
latest block (most to the right) is acknowledged the window is shifted, so that 
new data can come in. In the example of Fig. 7, the last oldest block (hatched 

25 with left tilt) in a window of an RLC 30, 32 is negatively acknowledged. There- 
fore, this block is retransmitted. All horizontally hatched blocks have positively 
been acknowledged, whereas the hatched blocks with right tilt are waiting for 
acknowledgement. They can be in the buffer of a Node-B 20, 22, in the air in- 
terface or their acknowledgement can be on its way. The block with the re- 

30 transmission will without the ideas presented in this report be put at the end of 
the queue in the Node-B 20, 22, which will mean that the time spend before a 
positive acknowledgement is received will increase. Before this block is ac- 
knowledged, the RLC 30, 32 cannot send any new blocks since this block is 
the last block in the RLC window. This is called stalling and will lead to a lower 

35 throughput for the user. 
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SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a scheduling scheme for access 
networks, by means of which retransmission delay can be decreased even with 
large buffer storage at the Node-B. 

5 This object is achieved by a method of scheduling data packets in a network de- 
vice of an access network, the method comprising the steps of: 

providing to said network device an information indicating a retransmission 
status of a data packet; and 

allocating a scheduling priority to said data packet based on said retransmis- 
10 sion status information. 

Furthermore, the above object is achieved by a system for scheduling data pack- 
ets in an access network, said system comprising: 

at least one network controller device for providing an information indicating a 
retransmission status of a data packet; and 

15 at least one network device for allocating a scheduling priority to said data 

packet based on said retransmission status information. 

Accordingly, retransmitted data packets can be prioritized during scheduling to 
thereby reduce the retransmission delay and increase the throughput as seen by 
the application or user. Large buffer storages can thus be allowed for at the base 
20 station devices, while the risk of RLC stalling and TCP retransmission is mini- 
mized. 

The information may be provided as a flag information in a payload portion or in a 
header portion of a data frame comprising the data packet. This flag information 
can be allocated to the data packet. It may indicate whether the data packet or the 
25 data frame, respectively, is retransmitted or not. Thereby, a straightforward solu- 
tion requiring minor modifications at the network controller devices can be pro- 
vided. Any spare bit in the header or payload portion can be used to convey the 
flag information set by a dedicated setting operation at the network controller de- 
vice. 
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As an alternative, the information may be provided in an out-band signaling. 

The data packet may be a MAC-d PDU, and the data frame may be an HS-DSCH 
data frame. The provided information may be set based on a corresponding infor- 
mation received from the RLC protocol layer. 

5 Furthermore, the allocation step may comprise the step of placing the data packet 
at a predetermined position in a buffer queue of the base station device. Specifi- 
cally, the data packet may be placed to the front position of the buffer queue if the 
provided information indicates a retransmission. The allocation step may comprise 
the step of adjusting a reordering of the buffer queue if the information indicates a 
1 0 retransmitted data packet. 

Alternatively, the allocation step may comprise the step of placing the data packet 
based on the provided information either to a retransmission buffer or to a first- 
transmission buffer. Then, data packets stored in the first-transmission buffer are 
scheduled when the retransmission buffer is empty. Hence, the network device 
1 5 may be arranged to schedule data packets of the first-transmission buffer after all 
data packets of the retransmission buffer have been schedule. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following, the present invention will be described in greater detail based on 
preferred embodiments with reference to the accompanying drawings, in which: 

20 Fig. 1 shows a schematic diagram of a network architecture in which the present 
invention can be implemented; 

Fig. 2 shows a schematic diagram of a frame structure according to a first em- 
bodiment; 

Fig. 3 shows a schematic diagram of a frame structure according to a second em- 
25 bodiment; 

Fig. 4 shows a schematic diagram of a signaling procedure for forwarding a re- 
transmission information according to the first and second embodiments; 
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Fig. 5 shows a schematic block diagram of a scheduling function according to a 
first example; 

Fig. 6 shows a schematic block diagram of a scheduling function according to a 
second example; and 

5 Fig. 7 shows a schematic block diagram of a conventional window-based RLC 
transmission with a stalling situation. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The embodiments of the present invention will now be described on the basis of a 
third generation WCDMA radio access network architecture as shown in Fig. 1 . 

10 Fig. 1 shows a terminal device or UE 10 connected via an air interface to a first 
Node-B 20 and/or a second Node-B 22. The first and second Node-Bs 20, 22 are 
connected via respective lub interfaces to first and second radio network control- 
lers (RNCs) 30, 32 which are connected to each other via a lur interface. The 
Node-Bs 20, 22 are logical nodes responsible for radio transmission and reception 

15 in one or more cells to/from the UE 10 and terminate the lub interface towards the 
respective RNCs 30, 32. The RNCs 30, 32 are in charge of controlling use and 
integrity of radio resources within the radio access network. Furthermore, the 
RNCs 30, 32 provide connections to a third generation core network 40, e.g. a 
UMTS (Universal Mobile Telecommunications System) network for both circuit- 

20 switched traffic via a lu-CS interface and packet-switched traffic via a lu-PS inter- 
face. The existence of an open standardized lur interface is essential for proper 
network operation, including soft handover support in a multi-vendor environment. 

According to the embodiments of the present invention, a mechanism is provided 
to put data packets of RLC retransmissions in front of a buffer queue of a schedul- 

25 ing function provided in the Node-Bs 20, 22 and related to the relevant traffic 
stream. To achieve this, a retransmission flag RF is introduced indicating a re- 
transmission of the concerned data packet or data frame. Of course, other indica- 
tion methods based on in-band and/or out-band signaling, i.e. within the con- 
cerned user channel and/or via a separate control channel, can be used as well. 

30 The Node-Bs 20, 22 can then adjust a reordering of the queue of data packets, if a 
data packet with a set retransmission flag arrives. An alternative is that the Node-B 
uses two queues per traffic stream. One can be used for first transmissions and 
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the other for RLC retransmissions. Once a user is to be scheduled, data is first 
read out of the retransmission buffer. When this one is empty, the original data can 
be scheduled. 

5 These measures allow for large buffer storage in the Node-Bs 20, 22 and therefore 
fast scheduling while simultaneously minimizing the RLC retransmission time.. 
This provides the advantage that the risks of TCP timeouts and RLC stalling are 
reduced, while L2 buffer requirements are loosened, since retransmission ac- 
knowledgments arrive faster due to the reduced RTF". 

10 

At the RNCs 30, 32, MAC layer processing is arranged to set the retransmission 
flag RF for a retransmitted data packet or data frame. 

Fig. 2 shows a first embodiment of a structure of an HS-DSCH data frame, where 
15 each MAC-d PDU has an allocated RLC retransmission flag RF. As can be gath- 
ered from Fig. 2, retransmission flags RLC are provided for each MAC-d PDU in 
the payload portion of the data frame. Some of the spare bits available in the data 
frame can be used as RLC retransmission flags. The first embodiment relates to 
the case that each MAC-d PDU can be marked as an RLC retransmission or not. 
20 The RLC retransmission flag is set by the MAC-d protocol layer according to the 
retransmission status of the concerned MAC-d PDU, which the MAC-d protocol 
layer derive or obtain from the RLC layer. In the present embodiments, one bit is 
used per MAC-d PDU, which contains one RLC PDU. The location of the bit of the 
retransmission flag RF can be just in front of the MAC-d PDU. However, it can also 
25 be located at some other place. In Fig. 2, spare bit No. 4, of the spare bits in front 
of each MAC-d PDU is used as the retransmission flag RF. For example, if the 
retransmission flag RF is set to "1", the respective MAC-d PDU is a retransmitted 
data packet, and if it is set to "0", the respective MAC-d PDU is transmitted for the 
first time. Of course, the opposite setting logic may be used as well. 

30 

Fig. 3 shows a second embodiment of the structure of the HS-DSCH data frame, 
where one HS-DSCH data frame has only one RLC retransmission flag RF allo- 
cated to the whole data frame, i.e. to all MAC-d PDUs in the payload portion. In 
this case, there is only one RLC retransmission flag provided in the header portion 
35 of the data frame. This means that all the MAC-d PDUs in the payload portion of 
the HS-DSCH data frame are retransmission packets in case the RLC retransmis- 
sion flag is set. 
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Fig. 4 shows an example of a signaling and processing flow in case RLC retrans- 
mission flag(s) RF is/are included in the HS-DSCH data frame. This signaling flow 
covers both of the above first and second embodiments. 

5 In the example of Fig. 4, one of the RNCs 30, 32 of Fig. 1 , e.g. the lower RNC 32, 
is a Drift RNC (D-RNC), and the other, e.g. the upper RNC 30, is a serving RNC 
(S-RNC), as regarded from the viewpoint of the UE 10. The S-RNC 30 is in charge 
of the RRC (Radio Resource Control) connection between the UE 10 and the radio 
access network. Thus, the S-RNC 30 terminates the lu connection. The D-RNC 32 

10 supports the S-RNC 30 with radio resources when the connection between the 
radio access network and the UE 10 needs to use cell(s) controlled by the D-RNC 
32, e.g. via the Node-B 22. According to Fig. 4, the S-RNC 30 generates a HS- 
DSCH data frame with a retransmission flag setting as RLC retransmission indica- 
tor and forwards the data frame to the D-RNC 32 using an HS-DSCH frame proto- 

15 col (HS-DSCH FP) signaling (step 1). Then, the D-RNC 32 forwards the HS-DSCH 
data frame to the Node-B 22 again using the HS-DSCH FP signaling (step 2). At 
the Node-B 22, a packet scheduling functionality or packet scheduler considers 
the retransmission flag setting during its scheduling operation (step 3). If the UE 
10 is located within the coverage area of the cells controlled by the S-RNC 30, the 

20 HS-DSCH data frame can be forwarded directly to the UE 1 0. 

Once the Node-B 22 has received the flag information RF, it will utilize it during the 
packet scheduling. Possible ways of prioritizing RLC retransmissions in the Node- 
Bs 20, 22 are described in the following based on Figs. 5 and 6. 

25 

The manner in which queued data packets are selected for transmission on the 
link is known as link scheduling discipline. Figs. 5 and 6 show first and second ex- 
amples of a queuing model abstraction, e.g. for a Fist-in-First-out (FIFO) link 
scheduling principle. Packets arriving at the link output queue are queued for 
30 transmission if the link is currently busy transmitting another packet. The conven- 
tional scheduling function selects packets for link transmission in the same order in 
which they arrived at the link queue. 

Fig. 5 shows a scheduling function according to the first example which can be 
35 used in connection with both first and second embodiments. The Node-Bs 20, 22 
comprise a checking functionality or unit 210 for checking the retransmission flag 
setting of a received data frame or data packet.. Based on the detected flag set- 
ting, a scheduler functionality 220 is controlled so as to allocated a scheduling pri- 
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ority to the concerned data packet or data frame, e.g., by adjusting the queue or- 
der of data packets in a buffer memory 230 to place retransmitted data packets at 
a front position of the queue. Thereby, the queue of data packets in the buffer 
memory 230 is reordered to prioritize retransmitted data packets. In particular, re- 
5 transmitted data packets may be placed in front of the queue. 

Fig. 6 shows a scheduling function according to the second example which also 
can be used in connection with both first and second embodiments. Here, two 
buffer memories 230, 240 are provided, i.e. a retransmission buffer memory 240 

10 for storing retransmitted data packets and a first-transmission buffer memory 230 
for storing data packets transmitted for the first time. Furthermore, a controllable 
switching functionality 250 is provided which can be controlled by the scheduler 
220 in response to the checking result of the checking unit 210 so as to switch or 
place the received data packet to one of the buffer memories 230, 240 based on 

15 the setting of the allocated retransmission flag RF. The switching unit may be 
implemented as hardware function, e.g. a demultiplexer, a semiconductor switch 
or a logical gate, or a software function controlling a memory read/write operation. 
The scheduler functionality 220 is adapted to schedule the data packets stored in 
the retransmission buffer memory 240 at first. Then, a selection functionality 260 

20 can be provided which selects the first-transmission buffer 230 as soon as the re- 
transmission buffer memory 240 is empty, so that the non-retransmitted data pack- 
ets are then scheduled by the scheduler 220. As an alternative, the selection of 
the selection functionalty 260 may be provided by the scheduler functionality 220, 
such that the selection functionality 260 can be dispensed with. 

25 

The scheduling functionalities according to the above first and second examples 
may be implemented in the Node-Bs 20, 22 as concrete hardware functions or as 
software routines controlling a processing unit with an allocated read/write or ran- 
dom access memory. 

30 

It is noted that the present invention is not restricted to the above preferred em- 
bodiments but can be used in any network device having a scheduling functional- 
ity. Moreover, any kind of signaling can be used for forwarding the retransmission 
information to the scheduling network element. The preferred embodiments may 
35 thus vary within the scope of the attached claims. 
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Claims 

1 . A method of scheduling data packets in a network device (20, 22) of an ac- 
cess network, said method comprising the steps of: 

(a) providing to said network device (20, 22) an information indicating a re- 
5 transmission status of a data packet; and 

(b) allocating a scheduling priority to said data packet based on said re- 
transmission status information. 

2. A method according to claim 1 , wherein said information is provided as a flag 
information (RF) in a payload portion of a data frame comprising said data 

1 0 packet 

3. A method according to claim 2, wherein said flag information (RF) is allo- 
cated to said data packet. 

4. A method according to claim 3, wherein said flag information indicates 
whether said data packet is retransmitted or not. 

15 5. A method according to claim 1 , wherein said information is provided as a flag 
information (RF) in a header portion of a data frame comprising said data 
packet. 

6. A method according to claim 2 or 5, wherein said flag information indicates 
whether said data frame is retransmitted or not. 

20 7. A method according to claim 1 , wherein said information is provided in an 
out-band signaling. 

8. A method according to any one of the preceding claims, wherein said data 
packet is a MAC-d PDU. 



9. 

25 



A method according to any one of claims 2 to 6, wherein said data frame is a 
HS-DSCH data frame. 
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10. A method according to any one of the preceding claims, wherein said infor- 
mation is set based on a corresponding information received from the RLC 
protocol layer. 

1 1 . A method according to any one of the preceding claims, wherein said alloca- 
5 tion step comprises placing said data packet at a predetermined position in a 

buffer queue of said base station device (20, 22). 

12. A method according to claim 1 1 , wherein said data packet is placed to the 
front position of said buffer queue if said provided information indicates a re- 
transmission. 

10 13. A method according to any one of the preceding claims, wherein said alloca- 
tion step comprises adjusting a reordering of a buffer queue of said network 
device (20, 22) if said information indicates a retransmitted data packet. 



14. A method according to any one of claims 1 to 10, wherein said allocation step 
comprises placing said data packet based on said provided information either 

15 to a retransmission buffer or to a first-transmission buffer. 

15. A method according to claim 14, wherein data packets stored in said first- 
transmission buffer arp scheduled when said retransmission buffer is empty. 

1 6. A system for scheduling data packets in an access network, said system 
comprising: 



20 (a) at least one network controller device (30, 32) for providing an informa- 

tion indicating a retransmission status of a data packet; and 



(b) at least one network device (20, 22) for allocating a scheduling priority 
to said data packet based on said retransmission status information. 



17. 

25 



A system according to claim 16, wherein said network device is a Node-B 
device (20, 22), said network controller device is a radio network controller 
device (10), and said access network is a radio access network. 
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18. A system according to claim 16 or 17, wherein said at least one network con- 
troller device (30, 32) is adapted to provide said information in an out-band 
signaling. 

19. A system according to any one of claims 16 to 18, wherein said network de- 
5 vice (20, 22) is adapted to allocate said scheduling priority by placing said 

data packet at a predetermined position within a buffer queue. 

20. A system according to any one of claims 16 to 18, wherein said network de- 
vice (20, 22) is adapted to allocate said scheduling priority by placing said 
data packet either to a retransmission buffer or to a first-transmission buffer, 

1 0 based on said provided information. 

21 . A system according to claim 20, wherein said network device (20, 22) is ar- 
ranged to schedule data packets of said first-transmission buffer after all data 
packets of said retransmission buffer have been scheduled. 

22. A network device adapted to be used in a system according to any one of 
15 claims 16 to 21. 

23. A network device according to claim 22, wherein said network device is a 
base station device (20, 22). 

24. A network controlling device adapted to be used in a system according to any 
one of claims 16 to 21. 
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